Clean Version of Amended Specification and Claims 

Please amend the following paragraph spanning page 12 lines 12-20 through page 13 lines 1 
and 2 as follows: 

Transaction processing is preferably managed through interaction 
between database server 116, authorization system 108, and a transaction 
capture module 112. As can be seen from Figure 4, database server 116 
suitably communicates card/account status information to authorization 
system 108. Status information generally includes account balance updates, 
status changes or the like for the various card accounts. For example, new 
cards are preferably assigned a "hold" status in authorization system 108 until 
consumer 100 initializes and validates the card as described above, at which 
time the authorization system preferably changes the status from "hold" to 
"pass" (or similar terms). A "hold" status is also preferably assigned if an 
account balance decreases below a minimum amount, or if a card is lost or 
stolen or the like. Accounts/cards that are assigned a "hold" status are 
preferably rejected by authorization system 108 in any subsequent requests 
for transaction approval. 

Please amend the following paragraph spanning page 13 lines 3-21 and page 14 lines 1 and 2 
as follows: 

Point of sale terminal 104 is any device that is capable of identifying and 
gathering data from any stored value product. For example, point of sale 
terminal 104 could be implemented as an actual terminal in a store, an 
Internet server, a telephone system, a card reader in a vending machine, an 
automatic teller machine, or any other device that is capable of accepting 
stored value information in financial transactions. Point of sale terminal 104 
suitably communicates with authorization system 108 to approve or reject 
transactions based upon information available to the authorization system 
108 from database server 116. Alternatively, authorization system 108 
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supplements information from database server 116 with information obtained 
from other external sources (not shown) such as external authorization 
systems, credit reporting bureaus, etc. Authorization preferably takes place in 
real time, but in some embodiments the authorization is accomplished using a 
polling or batch processing scheme. In a preferred embodiment, when a 
consumer 100 presents a stored value card or enters an account at a point of 
sale terminal 104, the terminal sends an authorization request for the 
transaction to authorization system 108. Additionally, for some transactions 
(such as those involving very small amounts of money) point of sale terminal 
104 may not transmit an authorization request at all. Although authorization 
may take place over any communications medium, authorization preferably 
occurs over a data communications link such as a telephone link, a leased 
line, the Internet, a wide area network, or the like. 

Please amend the following paragraph from page 14 lines 3-10 as follows: 

If the transaction is authorized, the transaction is preferably completed at 
point of sale terminal 104. Point of sale terminal 104 generally requests 
information such as the transaction amount and the identity of the stored 
value product used to pay for the transaction and this information is then 
suitably transmitted to transaction capture module 112 for settlement. To 
facilitate batch processing of settlement requests, merchants generally store 
information for multiple transactions. Alternatively, settlement requests are 
suitably transmitted in real time or are suitably polled by transaction capture 
module 112. 

Please amend the following paragraph from page 14 lines 1 1-21 as follows: 

With continued reference to Figure 4, transaction capture module 112 suitably 
captures financial transaction data from POS terminal 104 and routes this 
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information to database server 116. During a purchase transaction involving 
a stored value product, funds are suitably transferred from an account 
associated with a stored value card into a merchant's account. Records for 
card and merchant accounts are generally accessible by database server 
116, and are preferably maintained within database 142 (not shown in Figure 
4). A balancing system 118 is preferably located between database server 
116 and transaction processing module 112 to verify transaction data. 
Balancing system 118 is any computer system that provides a check based 
upon data received from database server 116 and transaction processing 
module 112. 

Please amend the following paragraph from page 15 lines 1-22 as follows: 

As best shown in Figure 5, a single report generator 136 preferably 
generates reports (1) for client system 138 using stored value products, as 
described above; (2) for merchants 140 that accept stored value products as 
compensation for goods or services; or (3) for consumers 100 that receive, for 
example, periodic statements of their accounts and transactions. 
Alternatively, multiple report generators 136 create various reports. As 
another alternative, database server 116 internally generates some or all 
reports without the use of an external report generator 136. In some 
embodiments of the invention, reports are generated in real-time (i.e. as 
requested by the account manager, the consumer, the database server 116, 
or any another entity). Alternatively, reports are processed in varying 
embodiments in batches, at predetermined times, when polled by the report 
generator, or by any other timing arrangement. Report generator 136 
preferably retrieves relevant data from a database associated with database 
server 116. In other embodiments, database server 116 provides necessary 
data to report generator 136 as part of a report generation request. 
Alternatively, database server 116 suitably sends a pointer (such as a 
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memory address accessible via a shared bus, or a uniform resource locator 
(URL), or any other pointer) to information that is stored. After obtaining data 
for the report requested, report generator 136 formats the data and provides 
the data to the proper client system 1 38. Various report generating systems 
are known in the prior art, and any report formatting system may be used in 
accord with the present invention. 

Please amend the following paragraph from page 16 lines 1-15 as follows: 

Figure 6 shows an exemplary embodiment of a combined system for adding 
cards, handling transactions and processing reports. As can be readily 
ascertained from Figure 6, a preferred embodiment of a stored value 
transaction system includes a database server 116 supporting multiple stored 
value products, each product preferably being associated with a particular 
client 138. Database server 116 preferably receives input from client system 
138 and from a transaction capture module 112, as well as optional online 
input from consumers or customer service representatives 134. Stored value 
cards and accounts are preferably registered with an authorization server 108 
that is configured to approve or deny individual transactions at various point 
of sale terminals such as terminal 104 in the drawing figures. Preferably, 
database server 116 communicates with a report generating system 136 that 
is configured to assemble data into reports for client systems 138, merchants 
140 and/or consumers 100, thereby formatting and simplifying data output 
from database server 116. 

Please amend the following paragraph from page 23 lines 3-11 as follows: 

Customer records are preferably maintained in a customer data subsystem 
172 that generally implements a single database record for each customer 
even though the customer may use multiple stored value products. Card 
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data, account data, client data customer data and the like all generally reside 
within customer information subsystem 172, which frequently communicates 
with objects from the products, funding, transaction processing and address 
subsystems described herein. Additionally, many user interface elements 
such as screens and access control are generally contained within the client 
demographics subsystem. 

Please amend the following paragraph spanning page 23 line 1 8 to page 24 line 6 as follows: 

Addresses (including, for example, customer billing addresses, merchant 
addresses and the like) are preferably maintained in address subsystem 160. 
Address subsystem 160 generally houses address information and provides 
an interface with all other subsystems needing address information, such as 
the customer and merchant data subsystems 172 and 168, respectively. 
Address subsystem 160 suitably provides a single point for maintaining 
substantially all of the address information stored in database 142, and 
preferably supports multiple addresses for each person (e.g. home, business 
and Internet addresses, among others). Other objects in address subsystem 
160 preferably support temporary addresses, optionally with an associated 
"effective date" such that forwarding addresses, traveling addresses, and the 
like are supported. 

Please amend the following paragraph from page 25 lines 11-17 as follows: 

Financial control subsystem 164 generally includes objects that are 
configured to substantially protect the financial integrity of database system 
116. Generally, financial control system 164 receives data from transaction 
capture module 112, as well as funding subsystem 158 to maintain accurate 
account balance information. Financial control system 164 optionally includes 
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objects that implement an interface to disputes and adjustments subsystems 
(not shown). 

In the paragraph spanning page 27 line 19 to page 28 line 12: 

Referring now to Figure 9, stored value products 186 are created using 
various objects from repository 144. Generally speaking, users create new 
products in accordance with a particular business unit 188 by selecting 
suitable objects from repository 144 that correspond to those attributes and 
functionalities desired in the new product 186. For example, a user may 
select, among others, an object for creating a card, various objects for storing 
value in an account associated with the card (or on the card itself), an object 
to manage financial transactions, and an object to generate reports for 
consumers. When these objects are selected, database server suitably 
assembles a product structure that references the various objects requested. 
In a preferred embodiment, product structures are tables of pointers to the 
various objects in repository 144, but any suitable method of organizing the 
various objects (such as in a data structure or in a database record) could be 
used. When the product executes, database server 116 retrieves the 
particular objects requested. Because this method of constructing products 
substantially reuses objects of pre-written code, design and implementation 
times are significantly reduced. 

IN THE CLAIMS 

20. A system for facilitating a plurality of stored value products, the system 
comprising: 

a database facilitating the storage and retrieval of customer data, 
merchant data, and a plurality of objects; 
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